Skip to content

Conversation

@jiparis
Copy link
Member

@jiparis jiparis commented Dec 15, 2025

This PR allows to configure individual policy evaluations as attestation gates during att push operations. A new gate property has been added to the policy attachment:

Example contract:

apiVersion: chainloop.dev/v1
kind: Contract
metadata:
  name: gate-contract
  description: Test contract with gate
spec:
  policies:
    attestation:
      - ref: file://test/gate-policy.yaml
        gate: true

Example policy:

apiVersion: workflowcontract.chainloop.dev/v1
kind: Policy
metadata:
  name: policy-with-gate
spec:
  policies:
    - kind: ATTESTATION
      embedded: |
        package main
        import rego.v1
        
        result := {"violations": ["Gated policy violation"]}

Attestation process:

> chainloop att init --workflow gate-wf --project gate-project --contract test/gate-contract.yaml
This command will run against the organization "my-org"
Please confirm to continue y/N
y
INF Attestation initialized! now you can check its status or add materials to it
┌───────────────────────────┬──────────────────────────────────────────┐
│ Initialized At            │ 15 Dec 25 19:04 UTC                      │
├───────────────────────────┼──────────────────────────────────────────┤
│ Attestation ID            │ 084d6158-c7c4-4efc-9cb3-35cc904301ce     │
│ Organization              │ my-org                                   │
│ Name                      │ gate-wf                                  │
│ Project                   │ gate-project                             │
│ Version                   │ v1.62.1+next (prerelease)                │
│ Contract                  │ gate-project-gate-wf (revision 1)        │
│ Policy violation strategy │ ADVISORY                                 │
│ Policies                  │ ------                                   │
│                           │ policy-with-gate: Gated policy violation │
└───────────────────────────┴──────────────────────────────────────────┘

> chainloop att push
INF push completed
┌───────────────────────────┬─────────────────────────────────────────────────────────────────────────┐
│ Initialized At            │ 16 Dec 25 09:15 UTC                                                     │
├───────────────────────────┼─────────────────────────────────────────────────────────────────────────┤
│ Attestation ID            │ f5c9fda7-47f5-46bb-8146-bdad1f390cfa                                    │
│ Digest                    │ sha256:526b12ec0318637c77267f6625ad59d81383d93becf8bfbc1e3dac8baae95837 │
│ Organization              │ my-org                                                                  │
│ Name                      │ gate-wf                                                                 │
│ Project                   │ gate-project                                                            │
│ Version                   │ v1.62.1+next (prerelease)                                               │
│ Contract                  │ gate-project-gate-wf (revision 1)                                       │
│ Policy violation strategy │ ADVISORY                                                                │
│ Policies                  │ ------                                                                  │
│                           │ policy-with-gate (gate): gate policy triggered                          │
└───────────────────────────┴─────────────────────────────────────────────────────────────────────────┘
ERR the policy "policy-with-gate" is configured as a gate and has violations
exit status 4

Note that this setting is independent to the global policy violation strategy configured at the org level.

@jiparis jiparis requested review from javirln and migmartri December 15, 2025 19:05
@migmartri
Copy link
Member

A couple of questions

  • Do we still send the attestation up but mark is as gated? similarly to what we do with the policy evaluation enforced?
  • If the gated policy is a material one, do we still only fail on att push? This seems consistent but double checking

Copy link
Member

@migmartri migmartri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jiparis

I left a couple of comments, I am interested in knowing how this behavior related to our current policy enforcement mechanism, as in if the data is sent to chainloop, marked as enforced, etc.

logger.Warn().Msg(exceptionBypassPolicyCheck)
continue
}
return fmt.Errorf("your contract requires the policy %q to pass before continuing", eval.Name)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't we return ErrBlockedByPolicyViolation so a custom error that also returns code error 3 or 4?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've just implemented a custom error. It now returns a 4

Signed-off-by: Jose I. Paris <[email protected]>
Signed-off-by: Jose I. Paris <[email protected]>
@migmartri
Copy link
Member

It would be nice if we could also add next to the policy information if it's a gate or not. Meaning that when you initialize, status or push, you get policy-name (gate)

Signed-off-by: Jose I. Paris <[email protected]>
@jiparis jiparis merged commit c163bf7 into chainloop-dev:main Dec 16, 2025
13 checks passed
@jiparis jiparis deleted the PFM-4030-gate branch December 16, 2025 12:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants